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INTRODUCTlCXa 


The  Ada  inplementation  described  cibove  was  tested  accordintj  to  the  Ada 
Validation  Procedures  [Pro92]  against  the  Ada  Standard  [AdaSS]  using  che 
current  Ada  Conpiler  Validation  Capability  (ACVC).  This  Validation  Summary 
Report  (VSR)  gives  an  accoxont  of  the  testing  of  this  Ada  implementation.  For 
any  technical  terms  used  in  this  report,  the  reader  is  referred  to  [Pro92]. 
A  detailed  description  of  the  ACVC  may  be  found  in  the  current  ACVC  User's 
Guide  [UG89]. 


1.1  USE  OF  THIS  t’ALIDATIW  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the  Ada 
Certification  Body  may  make  full  and  free  public  disclosure  of  this  report. 
In  the  United  States,  this  is  provided  in  accordance  with  the  "Freedom  of 
Information  Act"  (5  U.S.C.  #552).  The  results  of  this  validation  apply  only 
to  the  conpjters,  operating  systems,  and  compiler  versions  identified  in  this 
report. 

The  orgemizations  represented  on  the  signature  page  of  this  report  do  not 
represent  or  warrant  that  all  statements  set  forth  in  this  report  are 
accurate  and  conplete,  or  that  the  subject  inplementation  has  no 
nonconformities  to  the  Ada  Standard  other  than  those  presented.  Copies  of 
this  report  are  available  to  the  public  from  the  AVF  which  performed  this 
validation  or  from: 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield  VA  22161 

Questions  regarding  this  report  or  the  validation  test  results  should  be 
directed  to  the  AVF  vbich  performed  this  validation  or  to: 

Ada  Validation  Orgauiization 

Computer  and  Software  Engineering  Division 

Institute  for  Defense  Analyses 

1801  North  Beauregard  Street 

Alexandria  VA  22311-1772 


1-1 


INTRODUCTICN 


1 . 2  REFERENCES 

[Ad383]  Reference  Manual  fcr  the  Ada  Programming  Language, 

ANSI/MIL-STE>-l815A,  February  1983  and  ISO  86b2-l987. 

[Pro92]  Ada  Compiler  Validation  Procedures,  Version  3.1,  Ada  Joint 
Program  Office,  August  1992. 

[UG89]  Ada  Compiler  Validation  Capability  User's  Guide,  21  June  1989. 


1.3  ACVC  TEST  CLASSES 

Compliance  of  Ada  inplementations  is  tested  by  means  of  the  ACVC.  The  ACVC 
contains  a  collection  of  test  programs  structured  into  six  test  classes:  A, 
B,  C,  D,  E,  and  L.  The  first  letter  of  a  test  name  identifies  the  class  to 
which  it  belongs.  Class  A,  C,  D,  and  E  tests  are  executedsle.  Class  B  and 
class  L  tests  are  expected  to  produce  errors  at  compile  time  and  link  time, 
respectively. 

The  executable  tests  are  written  in  a  self-checking  manner  end  produce  a 
PASSED,  FAILED,  oc  NOT  APPLICABLE  message  indicating  the  result  when  they  are 
executed.  Three  Ada  library  units,  the  packages  REPORT  and  SPPRT13,  and  the 
procedure  CHECK_FILE  are  used  for  this  purpose.  The  package  REPORT  also 
provides  a  set  of  identity  functions  used  to  defeat  some  compiler 
optimizations  allowed  by  the  Ada  Standard  that  would  circumvent  a  test 
objective.  The  package  SPPRT13  is  used  by  many  tests  for  Chapter  of  the 
Ada  Steindard.  The  procedure  CHECK_FILE  is  used  to  check  the  contents  of  text 
files  written  by  some  of  the  Class  C  tests  for  Chapter  14  of  the  Ada 
Standard.  The  operation  of  REPORT  and  CHECK_FILE  is  checked  by  a  set  of 
executcible  tests.  If  these  units  are  not  operating  correctly,  validation 
testing  is  discontinued. 

Class  B  tests  check  that  a  conpiler  detects  illegal  language  usage.  Class  B 
tests  are  not  executable.  Each  test  in  this  class  is  compiled  and  the 
resulting  conpilation  listing  is  examined  to  verify  that  all  violations  of 
the  Ada  Standard  are  detected.  Some  of  the  class  B  tests  contain  legal  Ada 
code  which  must  not  be  flagged  illegal  by  the  compiler.  This  behavior  is 
also  verified. 

Class  L  tests  check  that  an  Ada  implenentation  correctly  detects  violation  of 
the  Ada  Stauidard  involving  multiple,  separately  compiled  units.  Errors  are 
expected  at  link  time,  and  execution  is  attempted. 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be  replaced  by 
inplementation-specific  values  —  for  example,  the  largest  integer.  A  list 
of  the  values  used  for  this  inplementation  is  provided  in  Appendix  A.  In 
addition  to  these  anticipated  test  modifications,  additional  changes  may  be 
required  to  remove  unforeseen  conflicts  between  the  tests  and 
implementation-dependent  characteristics.  The  modifications  required  for 
this  implementation  are  described  in  section  2.3. 
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For  each  Ada  implementation,  a  customized  test  suite  is  produced  by  the  AW. 
This  customization  consists  of  making  the  modifications  described  in  the 
preceding  paragraph,  removing  withdrawn  tests  (see  section  2.1),  and  possibly 
removing  some  inapplicable  tests  (see  section  2.2  and  [UG89]). 

In  order  to  pass  an  ACVC  an  Ada  implementation  must  process  each  test  of  the 
customized  test  suite  according  to  the  Ada  Standard. 


1.4  DEFINITION  OF  TERMS 

Ada  Conpiler  The  software  and  any  needed  hardware  that  have  to  be  added  to 
a  given  host  cind  target  con^juter  system  to  allow 

treuisformation  of  Ada  progreims  into  executable  form  and 
execution  thereof. 

Ada  Compiler  The  meeins  for  testing  compliance  of  Ada  implementations. 
Validation  consisting  of  the  test  suite,  the  support  programs,  the  ACVC 

Capability  user's  guide  and  the  template  for  the  validation  summary 

(ACVC)  report. 

Ada  An  Ada  compiler  with  its  host  conputer  system  and  its 

Implementation  target  conputer  system. 

Ada  Joint  The  part  of  the  certification  body  which  provides  policy  and 
Program  guidance  for  the  Ada  certification  system. 

Office  (AJPO) 

Ada  The  part  of  the  certification  body  which  carries  out  the 

Validation  procedures  required  to  establish  the  compliance  of  an  Ada 
Facility  (AW)  inplementation. 

Ada  The  part  of  the  certification  body  that  provides  technical 

Validation  guideuice  for  operations  of  the  Ada  certification  system. 

Orgeinization 
(AVO) 

Compliance  of  The  ability  of  the  implementation  to  pass  an  ACVC  version, 
an  Ada 

Implementation 

Computer  A  functional  unit,  consisting  of  one  or  more  computers  and 

System  associated  software,  that  uses  common  storage  for  all  or  part 

of  a  program  and  also  for  all  or  part  of  the  data  necessary 
for  the  execution  of  the  program;  executes  user-written  or 
user-designated  programs;  performs  user-designated  data 
meuiipulation,  including  arithmetic  operations  and  logic 
operations;  and  that  can  execute  programs  that  modify 
themselves  during  execution.  A  conputer  system  may  be  a 
stand-alone  unit  or  may  consist  of  several  inter-connected 
units. 
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Conformity 


Customer 


Declaration  of 
Conformance 


Host  Computer 
System 

Inappliccdsle 

test 

ISO 

LRM 


Operating 

System 


Target 

Computer 

System 

Validated  Ada 
Compiler 

Validated  Ada 
Implementation 

Validation 


Withdrawn 

test 


Fulfillment  by  a  product,  process,  or  service  of  all 
requirements  specified. 

An  individual  or  corporate  entity  who  enters  into  ein  agreement 
with  an  AVF  v^ich  specifies  the  terms  euid  conditions  for  AVF 
services  (of  any  kind)  to  be  performed. 

A  formal  statement  from  a  customer  assuring  that  conformity 
is  realized  or  attaineJDle  on  the  Ada  inplementation  for  which 
validation  status  is  realized. 

A  computer  system  vrtiere  Ada  source  programs  are  treinsformed 
into  executaible  form. 

A  test  that  contains  one  or  more  test  objectives  found  to  be 
irrelevcuit  for  the  given  Ada  implementation. 

International  Orgauiization  for  Standardization. 

The  Ada  standard,  or  Language  Reference  Mauiual,  published  as 
ANSI/MIL-STD-1815A-1983  and  ISO  8652-1987.  Citations  from  the 
LRM  take  the  form  "<section>.<subsection> :<paragraph> . " 

Software  that  controls  the  execution  of  progreuns  eind  that 
provides  services  such  as  resource  allocation,  scheduling, 
input/output  control,  and  data  management.  Usually,  operating 
systems  are  predominantly  software,  but  partial  or  complete 
hardware  implementations  are  possible. 

A  computer  system  where  the  executable  form  of  Ada  programs 
are  executed. 


The  conpiler  of  a  validated  Ada  implementation. 


An  Ada  implementation  that  has  been  validated  successfully 
either  by  AVF  testing  or  by  registration  [Pro92]. 

The  process  of  checking  the  confCLvJl.Ly  of  cc*.  Ada  compiler  to 
the  Ada  programming  language  and  of  issuing  a  certificate  for 
this  implementation. 

A  test  found  to  be  incorrect  and  not  used  in  conformity 
testing.  A  test  may  be  incorrect  because  it  has  cin  invalid 
test  objective,  fails  to  meet  its  test  objective,  or  contains 
erroneous  or  illegal  use  of  the  Ada  programming  language. 
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IMPLEMENTATIOl  DEPENDENCIES 


2 . 1  WITHDRAWN  TESTS 

The  following  tests  have  been  withdrawn  by  the  AVO.  The  rationale  for 
withdrawing  each  test  is  availedale  from  either  the  AVO  or  the  AVF.  The 
publication  date  for  this  list  of  witndrawn  tests  is  22  November  1993. 


B27005A 

E28005C 

B28006C 

C32203A 

C34006D 

C35507K 

C35507L 

C35507N 

C35507O 

C35507P 

C35508I 

C35508J 

C35508M 

C35508N 

C35702A 

C35702B 

C37310A 

B41308B 

C43004A 

C45114A 

C45346A 

C45612A 

C45612B 

C45612C 

C45651A 

C46022A 

B49008A 

B49008B 

A54B02A 

C55B06A 

A74006A 

C74308A 

B83022B 

B83022H 

B83025B 

B83025D 

C83026A 

B83026B 

C83041A 

B85001L 

C86001F 

C94021A 

C97116A 

C98003B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

BD1B02B 

BD1B06A 

AD1B08A 

BD2A02A 

CD2A21E 

CD2A23E 

CD2A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

BD3006A 

BD4008A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4024D 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

AD7206A 

BD80C2A 

BD8004C 

CD9005A 

CD9005B 

CnA20lE 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3116A 

CE3118A 

CE3411B 

CE3412B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

CE3814A 

CE3902B 

2.2  INAPPLICABLE  TESTS 

A  test  is  inapplicable  if  it  contains  test  objectives  which  are  irrelevant 
for  a  given  Ada  implementation.  Reasons  for  a  test's  inappliceibility  may  be 
supported  by  documents  issued  by  the  ISO  and  the  AJPO  known  as  Ada 
Commentaries  and  commonly  referenced  in  the  format  Al-ddddd.  For  this 
implementation,  the  following  tests  were  determined  to  be  inapplicable  for 
the  reasons  indicated;  references  to  Ada  Commentaries  are  included  as 
appropriate. 
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The  following  201  tests  have  floating-point  type  declarations  requiring 
more  digits  than  SYSTEM. MAX  DIGITS: 


C24113L..Y  (14  tests) 
C35706L. .Y  (14  tests) 
C35708L..Y  (14  tests) 
C45241L..Y  (14  tests) 
C45421L..Y  (14  tests) 
C45524L..Z  (15  tests) 
C45641L. .Y  (14  tests) 


C35705L..Y  (14  tests) 
C35707L..Y  (14  tests) 
C35802L..2  (15  tests) 
C45321L..Y  (14  tests) 
C45521L..Z  (15  tests) 
C45621L..Z  (15  tests) 
C46012L..Z  (15  tests) 


The  following  21  tests  check  for  the  predefined  type  SHORT_INTEGER;  for 
this  implementation,  there  is  no  such  type: 


C35404B 

C45412B 

C45611B 

B52004E 

CD7101E 


B36105C 

C45502B 

C45613B 

C55B07B 


C45231B 

C45503B 

C45614B 

B55B09D 


C45304B 

C45504D 

C45631B 

B86001V 


C45411B 

C45504E 

C45632B 

C86006D 


The  following  20  tests  check  for  the  predefined  type  LONG_INTEGETi;  for 
this  implementation,  there  is  no  such  type: 


C35404C 

C45502C 

C45613C 

C55B07A 


C45231C 

C45503C 

C45614C 

B55B09C 


C45304C 

C45504C 

C45631C 

B86001W 


C45411C 

C45504F 

C45632C 

C86006C 


C45412C 

C45611C 

B52004D 

CD7101F 


C35404D,  C45231D,  B86001X,  C86006E,  and  CD7101G  check  for  a  predefined 
integer  type  with  a  name  other  than  INTEGER,  LONG_INTEGER,  or 
SHORT_INTEGE3l;  for  this  implementation,  there  is  no  such  type. 


C35713B,  C45423B,  B86001T,  eu:d  C86006H  check  for  the  predefined  type 

SHORT_FLOAT;  for  this  implementation,  there  is  no  such  type. 


C35713D  auid  B86001Z  check  for  a  predefined  floating-point  type  with  a 
name  other  than  FLOAT,  LC1NG_FLCIAT,  or  SHORT_FLOAT;  for  this 
implementation,  there  is  no  such  type. 


C45531M..P  and  C45532M..P  (8  tests)  check  fixed-point  operations  for 
types  that  require  a  SYSTEM. MAX_MANTISSA  of  47  or  greater;  for  this 
implementation,  MAX_MANTISSA  is  less  than  47. 

C45624A..B  (2  tests)  check  that  the  proper  exception  is  raised  if 
MACHINE_OVERFLCWS  is  FALSE  for  floating  point  types  and  the  results  of 
various  floating-point  operations  lie  outside  the  remge  of  the  base 
type;  for  this  implementation,  MACHINE_OVEniFLCWS  is  TRUE. 


B86001Y  uses  the  name  of  a  predefined  fixed-point  type  other  them  type 
DURATION;  for  this  implementation,  there  is  no  such  type. 
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C96005B  uses  values  of  type  DURATION'S  base  type  that  are  outside  the 
range  of  type  DURATIC^J;  for  this  implementation,  the  ranges  are  the 
same. 


LA3004A.  .B,  EA3004C..D,  and  CA3004E..F  (6  tests)  check  pragma  INLINE  for 
procedures  and  functions;  this  implementation  does  not  support  pragma 
INLINE, 

CD1009C  checks  whether  a  length  clause  cam  specify  a  non-default  size 
for  a  floating-point  type;  this  implementation  does  not  support  such 
sizes. 

CD2A84A,  CD2Aa4E,  CD2A84l.,J  (2  tests),  cuid  CD2A840  use  length  clauses 
to  specify  non-default  sizes  for  access  types;  this  inplementation  does 
not  support  such  sizes. 

CD2B15B  checks  that  -STORAGE  ERROR  is  raised  when  the  storage  size 
specified  for  a  collection  Ts  too  small  to  hold  a  single  value  of  the 
designated  type;  this  implementation  allocates  more  space  than  was 
specified  by  the  length  clause,  as  allowed  by  AI-00558. 

BD8001A,  BD8003A,  BD8004A.  .B  (2  tests),  and  AD801LA  use  machine  code 
insertions;  this  implementation  provides  no  package  MACHINE_CODE . 

AE2101H,  EE2401D,  cind  EE2401G  use  instantiations  of  package  DIRECT_I0 
with  unconstrained  array  types  and  record  types  with  discriminants 
without  defaults;  these  instantiations  are  rejected  by  this  conpiler. 

The  tests  listed  in  the  following  tcible  check  that  USE  ERROR  is  raised 
if  the  given  file  operations  are  not  supported  for  the  given  combination 
of  mode  eind  access  method;  this  implementation  supports  these 
operations. 

Test  File  Operation  Mode  File  Access  Method 


CE2102D 

CREATE 

IN  FILE 

SEQUENTIAL  10 

CE2102E 

CREATE 

OUT  FILE 

SEWENTLAL  10 

CE2102F 

CREATE 

INOUT  FILE 

DIRECT  10 

CE2102I 

CREATE 

IN  FILE 

DIRECT  10 

CE2102J 

CREATE 

OUT  FILE 

DIRECT  10 

CE2102N 

OPEN 

IN  FILE 

SEQUENTIAL  10 

CE2102O 

RESET 

IN  FILE 

SEQUENTIAL  10 

CE2102P 

OPEN 

OUT  FILE 

SEQUENTIAL  10 

CE2102Q 

RESET 

OUT  FILE 

SEQUENTIAL  10 

CE2102R 

OPEN 

INOUT  FILE 

DIRECT  10 

CE2102S 

RESET 

INOUT  FILE 

DIRECT  10 

CE2102T 

OPEN 

IN  FILE 

DIRECT  10 

CE2102U 

RESET 

IN  FILE 

DIRECT  10 

CE2102V 

OPEN 

OUT  FILE 

DIRECT  10 

CE2102W 

RESET 

OUT  FILE 

DIRECT_IO 

CE3102E 

CREATE 

IN_FILE 

TEXT  10 

CE3102F 

CE3102G 

RESET 

DELETE 

Any  Mode 

TEXT  10 

TEXT  10 
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CE3102I  CREATE  OUT_FILE  TEXT_IO 
CE3102J  OPEN  IN_FILE  TEXT_IO 
CE3102K  OPEN  CUT_FILE  TEXT_IO. 

CE2203A  checks  that  WRITE  raises  USE_ERROR  if  the  capacity  of  an 
external  sequential  file  is  exceeded;  this  inplementation  cannot 
restrict  file  capacity. 

CE2403A  checks  that  WRITE  raises  USE_ERROR  if  the  capav  ity  of  an 
external  direct  file  is  exceeded;  this  implementation  cannot  restrict 
file  capacity. 

CE3111B,  CE3111D..E  (2  tests),  CE3114B,  and  CE3115A  check  operations  on 
text  files  vdien  multiple  internal  files  are  associated  with  the  same 
external  file  and  one  or  more  are  open  for  writing;  USE_ERROR  is  raised 
when  this  association  is  attempted. 

CE3304A  checks  that  SET_LINE^LENC?rH  and  SET_PAGE_LENGTH  raise  USE_ERROR 
if  they  specify  an  inapproprTate  value  for  the  external  file;  there  are 
no  inappropriate  values  for  this  implementation. 

CE3413B  checks  that  PAGE  raises  LAyOUT_ERf:OR  when  the  value  of  the  page 
number  exceeds  COUNT' LAST;  for  this  implementation,  the  value  of 
COUNT'LAST  is  greater  than  150000,  making  the  checking  of  this  objective 
impractical . 


2 . 3  TEST  MODIFICATIONS 

Modifications  (see  section  1.3)  were  required  for  122  tests. 

The  following  tests  were  split  into  two  or  more  tests  because  this 
implementation  did  not  report  the  violations  of  the  Ada  Stemdard  in  the  way 
expected  by  the  original  tests. 


B22003A 

B22003B 

B22004A 

B22004B 

B22004C 

B22005K 

B22005L 

B23002A 

B23004A 

B23004B 

B24001A 

B24001B 

B24001C 

B24005A 

B24005B 

B24007A 

B24009A 

B24104A 

B24204A 

B24204B 

B24204C 

B24204D 

B24204E 

B24204F 

B24205A 

B24206A 

B24206B 

B25002A 

B25002B 

B26001A 

B26002A 

B26005A 

B28003A 

B28003C 

B29001A 

B2A003A 

B2A003B 

B2A003C 

B2A003D 

B2A003E 

B2A003F 

B2A004A 

B2A005A 

B2A005B 

B2A007A 

B2A021A 

B32103A 

B33101A 

B33201B 

B33202B 

B33203B 

B33301A 

B33301B 

B35101A 

B36002A 

B37106A 

B37205A 

B37307B 

B38003A 

B38003B 

B38009A 

B38009B 

B38103A 

B38103B 

B38103C 

B38103D 

B38103E 

B41201A 

B44001A 

B44004A 

B44004B 

B44004C 

B45205A 

B48002A 

B48002D 

B51001A 

B53003A 

B55A01A 

B61005A 

B64006A 

B67001A 

B67001B 

B67001C 

B67001D 

B67001H 

B7100LA 

B71001G 

B71001M 

B74104A 

B74307B 

B83E01C 

B83E01D 

B85008G 

B85008H 

B91001H 

B95001D 

B95003A 

B95004A 

B95063A 

BAllOlE 

BB1006B 

BB3005A 

BC1013A 

BC1109A 

BC1109B 

BC1109C 

BC1109D 

BC1201A 

BC1206A 

BC1303F 

BC2001D 

BC2001E 

BC3003B 

BC3005B 
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BC3013A  BD2B14A  BD2C14A  BE2210A  BE2413A 

BC3204D  and  BC3205C  were  graded  passed  by  Evaluation  Modification  as  directed 
by  the  AVO.  These  tests  are  expected  to  produce  compilation  errors,  but  this 
implementation  compiles  the  units  without  error;  all  errors  are  detected  at 
link  time.  This  behavior  is  allowed  by  AI-00256,  as  the  units  are  illegal 
only  with  respect  to  units  that  they  do  not  depend  on. 

CE3804H  was  graded  passed  by  Evaluation  Modification  as  directed  by  the  AVD. 
This  test  requires  that  the  string  "-3.525"  can  be  read  from  a  file  using 
FLOAT_IO  and  that  ein  equality  conparison  with  the  n\jnneric  literal  '-3.525' 
will  evaluate  to  TRUE;  however,  because  -3.525  is  not  a  model  number,  this 
conparison  may  evaluate  to  FALSE  (LRM  4.9:12).  Ttiis  implementation's 
conpile-time  and  run-time  evaluation  algorithms  differ;  thus,  this  check  for 
equality  fails  and  Report. Failed  is  called  at  line  81,  vHhich  outputs  the 
message  "WIDTH  CHARACTE3^  NOT  READ."  All  other  checks  were  passed. 
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PROCESSING  INFORMATION 


3.1  TESTING  ENVIR(»1MENT 

The  Ada  implementation  tested  in  this  validation  effort  is  described 
adequately  by  the  information  given  in  the  initial  pages  of  this  report. 

For  technical  and  sales  information  about  this  Ada  inplementation,  contact: 

Jerry  Rudisin 

Rational  Software  Corporation 
2800  San  Tomas  Expressway 
Santa  Clara  CA  95051-0951 
(408)  496-3712 


Testing  of  this  Ada  inplementation  was  conducted  at  the  customer's  site  by  a 
validation  team  from  the  AVF. 


3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  In^jlementation  passes  a  given  ACVC  version  if  it  processes  each  test 
of  the  customized  test  suite  in  accordance  with  the  Ada  Progrzunming  Language 
Standard,  whether  the  test  is  applicable  or  inapplicable;  otherwise,  the  Ada 
Implementation  fails  the  ACVC  (Pro92]. 

For  all  processed  tests  (inapplicable  and  a^Jlicable),  a  result  was  obtained 
that  conforms  to  the  Ada  Programming  Language  Standard. 

The  list  of  items  below  gives  the  number  of  ACVC  tests  in  various  categories. 
All  tests  were  processed,  except  those  that  were  withdrawn  because  of  test 
errors  (item  b;  see  section  2.1),  those  that  require  a  floating-point 
precision  that  exceeds  the  inplementation's  maximum  precision  (item  e;  see 
section  2.2),  and  those  that  depend  on  the  support  of  a  file  system  —  if 
none  is  supported  (item  d).  All  tests  passed,  except  those  that  are  listed 
in  sections  2.1  and  2.2  (counted  in  items  b  and  f,  below). 
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a)  Total  Number  of  Applicable  Tests  3750 

b)  Total  Number  of  Withdrawn  Tests  104 

c)  Processed  Inapplicable  Tests  115 

d)  Non-Processed  I/O  Tests  0 

e)  Non-Processed  Floating-Point 

Precision  Tests  201 

f)  Total  Number  of  Inapplic3±)le  Tests  316  (c+d+e) 

g)  Total  Number  of  Tests  for  ACVC  1.11  4170  (a+bff) 


3.3  TEST  EXECUTION 

A  magnetic  tape  containing  the  customized  test  suite  (see  section  1.3)  was 
taken  on-site  by  the  validation  team  for  processing.  The  validation  tape  was 
loaded  on  a  machine  acting  as  a  file  server.  The  files  were  accessed  via 
automounted  NFS. 


After  the  test  files  were  loaded  onto  the  host  conputer,  the  full  set  of 
tests  was  processed  by  the  Ada  inplementation. 

The  tests  were  conpiled,  linked  and  executed  on  the  host  computer  system. 
The  results  were  captured  on  the  host  computer  system. 

Testing  was  performed  using  command  scripts  provided  by  the  customer  and 
reviewed  by  the  validation  team.  See  Appendix  B  for  a  complete  listing  of 
the  processing  options  for  this  implementation.  It  also  indicates  the 
default  options.  The  options  invoked  explicitly  for  validation  testing 
during  this  test  were: 


Option  I  Switch  Effect 

-listing_di rectory  <dir>  To  produce  a  listing  in  the  specified 

directory  <dir>. 

-compile  To  syntactically  eund  sememtically  analyze  a 

source  file  and  produce  eui  Ada  unit  (or 
units)  if  correct. 

-goal  linked  Produce  the  object  code  and  linked 

executcd^le  for  an  Ada  main  program. 


Test  output,  compiler  and  linker  listings,  eurxJ  job  logs  were  captured  on 
magnetic  tape  and  archived  at  the  AVF.  The  listings  examined  on-site  by  the 
validation  team  were  also  archived. 
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MACRO  PARAMETERS 


This  appendix  contains  the  macro  parameters  used  for  customizing  the  ACVC. 
The  meeming  2uid  purpose  of  these  parauneters  are  explained  in  (UG89].  The 
parameter  values  are  presented  in  two  tables.  The  first  table  lists  the 
values  that  are  defined  in  terms  of  the  naximum  input-line  length,  vdiich  is 
the  value  for  $MAX_IN_LEN — also  listed  here.  These  values  are  expressed  here 
as  Ada  string  aggregates,  where  "V”  represents  the  naximum  input-line  length. 


Macro  Parameter  Macro  Value 


$MAX_IN_LEN 

254 

—  Value  of  V 

$BIG_ID1 

(1. 

.V-1  'A', 

V 

->  '1') 

$BIG_ID2 

(1. 

.V-1  ->  'A', 

V 

->  '2') 

$BIG  ID3 

(1. 

.V/2  ->  'A') 

& 

'3'  & 

(1..V-1-V/2 

»> 

'A'  ) 

$BIG  ID4 

(1. 

.V/2  ->  'A') 

& 

'4'  & 

(1..V-1-V/2 

»> 

'A'  ) 

$BIG_INT_LIT 

(1. 

.V-3  ->  '0' ) 

& 

"298" 

$BIG_REAL_LIT 

(1. 

.V-5  ->  '0') 

& 

"690.0" 

$BIG_STRING1 

r  w  r 

&  (1..V/2  - 

>  ' 

A')  & 

$BIG_STRING2 

r  «  f 

&  (1..V-1-V/2 

->  'A')  &  '1 

$BLANKS 

(1. 

.V-20  ->  '  ' 

) 

$MAX_LEN_INT_BASED_LITERAL 

"2:"  &  (1..V-5  =>  '0')  &  "11:" 


$MAX_LEN_REAL_BASED_LITERAL 

"16:"  &  (1..V-7  «>  '0')  &  "F.E:" 
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$MAX_STRING_LITERAL  &  (1..V-2  ->  'A')  & 

The  follcjwing  table  lists  all  of  the  other  macro  parameters  and  their 
respective  values. 

Macro  Parameter  Macro  Value 

$ACC_SIZE  32 

$ALIGNMENT  1 

$COUNT_LAST  1000000000 

$DEFAULT_MEM_SIZE  2147483647 

$DEFAULT_STOR_UNIT  8 

$DEFAULT_SYS_NAME  SPARC_SOLARIS 

$DELTA_DOC  0 . 000_000_000_465_661_287_307_739_257_812_5 

$ENTRY_ADDRESS  SYSTEM. TO_ADDRESS  (30) 

$ENTRY_ADDRESS1  SYSTEM. TO_ADDRESS  (31) 

$ENTRY_ADDRESS2  SYSTEM. TO_ADDRESS  (2) 

$FIELD_LAST  2147483647 

$FILE_TERMINATOR  '  ' 

$FIXED_NAME  NO_SUCH_TYPE 

$FLOAT_NAME  NO_SUCH_TYPE 

$FORM_STRING  "" 

$FORM_STRING2  "CAN^m_RESTRICT_FILE_CAPACITY" 

$GREATER  THAN  DURATIC»I 

1.0 

$GREATER  THAN  DURATIW  BASE  LAST 

T31_073.0 

$GREATER_THAN_FLQAT_BASE  LAST 

1.TJE308 

$GREATER_THAN_FLQAT_SAFE  LARGE 

3.IE38 
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$GREATER_THAN_SHORT_FLClAT_SAFE  LARGE 

1.0E308 

$HIGH_PRIORITy  255 

$ILLEGAL_EXTERNAL_FILE_NAME1 

BAD/_CHARACTERS 

$ILLEGAL_EXTERNAL_FILE_NAME2 

CONTAINS/JWILDCARDS 

$ INAPPROPRIATE_LINE_LENGTH 

-1 


$  INAPPROPRIATE_PAGE_LENGTH 

-1 


$ INCLUDE_PRAGMA1 

$ INCLUDE_PRAGMA2 

$INTEGER_FIRST 

$INTEGER_LAST 

$INTEGER_LAST_PLUS_1  2147483648 

$I^r^ERFACE_LA^^GUAGE  C 

$LESS_THAN_DURATION  -1.0 

$LESS_THAN_DURATIC»J_BASE  FIRST 

-111  073.0 


PRAOIA  INCLUDE  ( "A28006D1 .TST" ) ; 
PRAGMA  INCLUDE  ( "B28006D1.TST" ) ; 
-2147483648 
2147483647 


$LINE_TERMINATOR 
$LOW  PRIORITY 


ASCII.LF 

0 


$MACHINE_CODE_STATEMENT 

NULL; 


$MACHINE_CODE_TYPE 

$MANTISSA_DOC 

$MAX_DIGITS 

$MAX_INT 

$MAX_INT_PLUS_1 

$MIN_INT 

$NAME 


NO_SUCH_TYPE 

31 

15 

2147483647 

2147483648 

-2147483648 

NO_SUCH_TYPE 
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$NAME_LIST 

SPARC_SOLARIS 

$NAME_SPECIFICATI0N1 

X2120A 

$NAME_SPECIFICATION2 

X2120B 

$NAME_SPECI FICATION3 

X3119A 

$NEG_BASED_INT 

16#FFFFFFFE# 

$NEW_MEM_SIZE 

2147483647 

$NEW_STOR_UNIT 

8 

$NEW_SYS_NAME 

SPARC_SOLARIS 

$PAGE_TERMINATOR 

ASCIl.FF 

$RECORD_DEFINITIC»I 

NEW  INTEGER; 

$RECORD_NAME 

NO_SUCH_MACHINE_CODE_TYPE 

$TASK_SIZE 

32 

$TASK_STORAGE_SIZE 

8192 

$TICK 

(1.0/60.0) 

$VARIABLE_ADDRESS 

FCNDECL . ADDRESSO 

$VARIABLE_ADDRESS1 

FCNDECL . ADDRESSl 

$VARIABLE_ADDRESS2 

FCNDECL. ADDRESS2 

$YOUR_PRAGMA 

EXPORTJDBJECT 
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a}MPILATIC»J  AND  LINKER  OPTIONS 


The  conpiler  and  linker  options  of  this  Ada  implementation,  as  described  in 
this  Appendix,  are  provided  by  the  customer.  Unless  specifically  noted 
otherwise,  references  in  this  appendix  are  to  compiler  documentation  and  not 
to  this  report. 
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APPENDIX  C 


APPENDIX  F  OF  THE  Ada  STANDAE® 


The  only  allowed  inplementation  dependencies  correspond  to 
inplementation-dependent  pragmas,  to  certain  machine-dependent  conventions  as 
mentioned  in  Chapter  13  of  the  Ada  Stemdard,  and  to  certain  allowed 
restrictions  on  representation  clauses.  The  implementation-dependent 
characteristics  of  this  Ada  inplementation,  as  described  in  this  Appendix, 
are  provided  by  the  customer.  Unless  specifically  noted  otherwise, 
references  in  this  i^pendix  are  to  compiler  documentation  and  not  to  this 
report.  Implementation-specific  portions  of  the  package  STANDARD,  which  are 
not  a  part  of  ^pendix  F,  are: 


package  STANDARD  is 


type  Integer  is  range  -2147483648  ..  2147483647; 

type  Float  is  digits  6 

range  -3.40282E+38  ..  3.40282E+38; 

type  Long_Float  is  digits  15 

range  -1.79769313486231E+308  ..  1.79769313486231E+308; 

type  IXiration  is  delta  0.000061035156 

range  -131072.00000000  ..  131071.9999389648437500000000; 


end  STANDARD; 
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Chapter  10 


LEM  Appendix  F:  Implementation- 
Dependent  Characteristics 


This  chapter  provides  Information  as  required  by  the  LRM 
Appendix  F.  The  Implementation-dependent  characteristics  of 
Rational  Ada  are  described  in  the  following  sections: 

■  “Pragmas"  on  page  79 

■  “Attributes’  on  page  101 

■  ‘Packages  Standard  and  System"  on  page  105 

■  "Representation  Clauses*  on  page  108 

■  ‘Implementation-Generated  Names"  on  page  1 10 

■  ‘Address  Clauses  (LRM  13.5)”  on  page  111 

■  ‘Unchecked  Programming*  on  page  111 

■  ‘Input/Output  Packages”  on  page  112 

■  ‘Other  Implementation- Dependent  Features"  on  page  114 


Pragmas 


This  section  provides: 

■  General  notes  about  pragma  error  handling 

■  A  table  of  Implementation  dependencies  in  the  predefined 
pragmas  from  LRM  Annex  B 

■  A  table  of  implementation-defined  pragmas 

■  Detailed  descriptions  of  each  of  the  Implementation-defined 
pragmas  startl^  on  page  83 

Error  Handling  for  Pragmas 

A  pragma  whose  existence,  placement,  or  arguments  do  not 
correspond  to  tfiose  allowed  Is  ignored,  by  default,  by  the 
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compiler  and  the  runtime  system.  This  means  that  a  warning 
Is  generated  If  the  compiler  detects  such  an  error,  but  in  any 
event  the  compilation  completes  successfully. 

Several  Apex  context  switches  allow  you,  however,  to  specify 
whether  to  treat  certain  classes  of  invalid  pragmas  as  errors 
that  prevent  successful  compilation  rather  than  as  warnings. 
See  Appendix  A,  “Switches,"  for  details  on  the  following 
switches; 

m  Reject_Bad_Lrm_Pragmas:  Affects  the  handling  of  Illegal 
LRM-defined  pragmas 

■  Reject_Bad_Ratlonal_Pragmas:  Affects  the  handling  of 
illegal  Rational  implementation-defined  pragmas 

■  Reject_Undefined_Pragmas:  Affects  the  handling  of 
pragmas  defined  neither  in  the  LRM  nor  In  this  Appendix  F 

If  more  than  one  of  the  same  pragma  is  specified  where  it  is  not 
appropriate  to  do  so  (for  example,  two  pragma  Mains  on  the 
same  unit),  the  first  one  is  used  and  the  others  generate 
warnings  at  compile  time. 

References 

■  pragma  warnings,  LRM  2.8(9),  2.8(  1 1) 

Predefined  Pragmas 

For  each  pragma  defined  in  Annex  B  of  the  LRM,  Table  10-1 
describes  the  extent  to  which  Rational  Ada  supports  it. 


Table  lO-J  Predejlned  Pragnutsfivm  IHM  Annex  B 


Predefined 

Pragma 

Level  of  Siqrport 

Controlled 

Always  impUdtly  In  effect  because  the  implementa¬ 
tion  does  not  support  automatic  garbage  collection 

Elaborate 

As  described  in  Annex  B 

Inline 

Has  no  efiect 

Interface 

As  described  in  Annex  B;  must  be  used  in  conjunc¬ 
tion  with  pragmas  Import_Procedure  and  Import- 
_Functlon 
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TcMm  10-1  Prmd^flnmd  Pragmamfrom  LRMAimmx  B  IContinusd) 
Predellned 

Pragma  Level  of  Support  _ 

List  Aa  described  in  Annex  B 


Memory  Size  Has  no  effect 


Optimize 


Pack 


Page 

Priority 


Has  an  effect  only  when  located  In  the  outermost 
scope,  where  It  applies  to  the  entire  compilation  unit; 
If  not  used,  the  value  SPACE  is  assumed.  See  “Set¬ 
ting  the  Optimization  Objective*  on  page  21 

As  described  In  Annex  B:  see  “Concepts  for  Object 
Slzea“  on  page  67 

As  described  In  Annex  B 

As  described  in  Annex  B  and  LRM  9.8(2);  the  default 
is  127 


Shared 


As  given  in  Annex  B;  has  an  effect  only  for  integer, 
enumeration,  access,  and  fixed  types 


Storage_Unlt  Has  no  effect 
Suppress  As  described  in  Annex  B 

SyBtem_Name  Has  no  effect  (there  Is  only  one  enumeration  literal  in 
the  type  Sy8tem.System_Name) 


Implementation-Defined  Pragmas 

Table  10-2  summarizes  ail  implementation-defined  pragmas  in 
Rational  Ada.  Each  pragma  is  described  in  more  detail  In  the 
following  subsections. 
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Tabla  10-2  Jmplmnmtation-Deflnmd  Pragmam 


Implementatlon- 
Deflned  Pragma 

Deacilptlon 

Assert 

Raises  an  exception  if  a  specified  Boolean 
expression  evaluates  to  False  at  run  time 

CollecUon_Pollcy 

Controls  memory  allocation  for  the  collec¬ 
tion  designated  by  an  access  type 

Ebcport_Functlon 

Creates  a  global  symbol  for  an  Ada  function 
so  that  it  can  be  called  by  non-Ada  code 

Export_ObJect 

Creates  a  global  symbol  for  an  Ada  object  so 
that  it  can  be  referenced  by  non-Ada  code 

Ebcport_Procedure 

Creates  a  global  symbol  for  an  Ada  proce¬ 
dure  so  that  it  can  be  called  by  non-Ada 
code 

Generlc_E’ollcy 

Tells  the  compiler  how  to  generate  code  for  a 
generic  and  Its  Instantiations 

Import_FuncUon 

Associates  the  global  symbol  for  a  non-Ada 
function  with  an  Ada  name  so  that  an  Ada 
subprogram  can  call  the  function 

Import_ObJect 

Associates  the  global  symbol  for  a  non -Ada 
object  with  an  Ada  name,  so  that  an  Ada 
subprogram  can  reference  the  object 

Import_Procedurc 

Associates  the  global  symbol  for  a  non -Ada 
procedure  with  an  Ada  name,  so  that  an  Ada 
subprogram  can  call  the  procedure 

Initialize 

Specifies  that  default  Initialization  be  car¬ 
ried  out  for  an  Imported  object  or  an  object 
referenced  by  an  address  clause 

lnstance_Pollcy 

Specifies  replicated  code  for  specific  instan¬ 
tiations  of  a  shared-code  generic 

Main 

Designates  an  Ada  main  unit  and  sp>ecifles 
aspects  of  its  run-time  behavior 

Must_Be_Constralned 

Indicates  whether  formal  private  and  limited 
private  types  within  a  generic  formal  part 
must  be  constrained 
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Tabic  10-2  bnplanKntation-D^flned  Pragnuis  (Continued} 


Impleiiicntation- 
Deflxwd  Pragma 

Daaciiption 

Slgnal_Handler 

Installs  a  procedure  as  a  UNIX  signal 
handler 

Suppress.All 

Suppresses  all  permitted  runtime  checks 

Suppress.Elaboratlon- 

_Checks 

Suppresses  elaboration  checks  for  a  specific 
compilation  unit 

Pragma  Assert 

Raises  an  exception  if  a  specified  Boolesin  expression  evaluates 
to  False  at  run  time.  The  syntax  is: 

prcgoMU  ASSCRT 

( [PBKDZCAIK  a>]  bool*«n_ajqpr*««ion)  ; 

Arguments 

a  Pr*<llc*ta:  The  Boolean  expression  to  be  evaluated  at  run 
time. 

Usage 

When  the  pragma  is  encountered  at  run  time,  the  BoolCcin 
expression  is  evaluated.  If  the  result  is  False,  the  System.Asser- 
tlon_Error  exception  is  raised;  if  the  result  is  True,  no  action  is 
taken. 

This  pragma  can  appear  anywhere  that  a  declaration  or  state¬ 
ment  is  allowed. 

Pragma  Collection_Policy 

Controls  memory  allocation  for  the  collection  designated  by  an 
access  type.  The  syntax  is; 

peegna  COIXJCCTXOM  POLZCY 


(AOCESSjrXFX 

■> 

meeem»_typm. 

ZHITZJajSZZX 

■> 

iategmr^mxprmmmion 

Kxmszazx 

-> 

boolmmn_jmxprmmmion] 

I, 

KxmsiOH_szzs  ■> 

±ntmgmr__mxpremmion] ) 

7x9’  Printed  Template,  rev.  1 .9 


83 


Chapter  10  LRM  Apperxlix  F:  Implementation-Dependent  Characteristics 


Arguments 

a  AccassjTypa:  The  access  type  on  which  to  perform  storage 
management. 

a  lnitial_Slsa:  The  size  In  storage  units  of  the  Initial  collec¬ 
tion  that  Is  created  for  an  access  type.  A  negative  value  is 
treated  as  0. 

a  Bxtanalbla:  Specifies  whether  the  collection  can  be 
extended.  If  True,  sets  the  extension  size  to  the  default  or 
specified  value  of  Elxtenslon_Sl2e:  otherwise.  Ebctension_Size 
Is  ignored.  The  default  value  is  True, 
a  Extanalon_Slza:  The  miniTnum  number  of  storage  units 
by  which  the  collection  will  be  extended,  when  needed,  if  it 
Is  extensible.  A  negative  value  Is  treated  as  0.  The  default 
value  Is  4.096  bytes. 

Usage 

The  pragma  must  appear  in  the  same  declarative  region  as  the 
access  type  to  which  It  applies,  after  the  access  type's  declara¬ 
tion  and  before  aity  forcing  occurrence  of  the  access  type.  If  the 
access  type  Is  a  private  type,  the  pragma  must  appear  in  the 
private  part  after  the  complete  access-type  declaration.  If  the 
pragma  appears  outside  the  specified  areas.  It  Is  Ignored. 

A  description  and  example  of  the  pragma’s  application  are 
provided  In  “Managing  Storage  for  Access  Types"  on  page  63. 

Notes 

■  The  arguments  must  be  specified  using  named  association. 

■  Only  one  Collectlon_Policy  pragma  Is  allowed  per  access 
type.  If  more  than  one  is  specified,  the  first  Is  applied  and 
the  rest  are  Ignored. 

■  When  an  access  type  has  an  associated  ’Storage_Slze 
clause,  any  Collectlon_Pollcy  pragma  for  that  access  type  is 
Ignored.  This  occurs  because  a  statement  of  the  form: 

for  X'8TaRA(a;_8ZZX  •lx«; 
is  functionally  equivalent  to: 
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pragm  COT.TXfitlOMJPOLICY 
(ACCX88_T»X  m>  X, 

XHZTXJa_8ZZS  aXxa, 

KXTSXSZBUe  ■>  rjtUK)  ; 

■  If  Inltlal.Size  Is  nonpositive  and  Extensible  is  False, 
attempting  to  execute  an  allocator  of  the  access  type  raises 
the  Storage.Emor  exception. 

References 

■  access  type.  LRM  3.8 

■  allocator.  LRM  4.8 

■  collection.  LRM  3.8 

■  forcing  occurrence.  LRM  13. 1(6) 

■  Storage_Error,  LRM  11.1 

■  Storage^Slze.  LRM  13.7.2 

Pragmas  Export_Function,  Export_Ob]ect,  and  Export_Procedure 

Creates  a  global  symbol  for  an  Ada  subprogram  (function  or 
procedure)  or  object  so  that  It  can  be  called  or  referenced  by 
non-Ada  code.  The  syntax  is: 

pragma  EXPORTjrOHCTXOB 


([ZBTCRHAL 

->1 

ijitamal_najBa 

L 

[KXTKiuaa. 

->1 

”  axtamaJ_naaa"  ] 

[, 

[pjuuuiRBtjrypKs 

->1 

paramat  ax^  typa^I  i  •  t  ] 

[. 

[BXSOLTjrXPX 

->1 

typa_marJk] 

[. 

[LAHCmUS 

->] 

langua9a_nama] )  ; 

pragma  EXPCS1T_08JXCT 

((IKTERBAL  >>]  Intamal  nama 


[EXTCMHAL  >>]  ”  axtamal_naaa"  ] ) ; 

•0 

: 

1 

CXPORT_PROCKDOPZ 

([ZHTERKXL 

->1 

in  e  azxia2_naaa 

L 

(CXTSUDU:. 

->1 

"  axtaniai_nama"  ] 

[, 

[PMAmraRjnpKs 

»>) 

paramata^typa__ii«t  ] 

I. 

[LAHCmUSX 

-» 

Ianguaga_nama] )  ; 
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Arguments 

■  intamal:  The  Ada  simple  name  of  the  Ada  subprogram  or 
object  to  be  exported.  For  fvmctlons.  this  can  al^  be  an 
operator  symbol. 

■  External:  An  optional  string  literal  that  specifies  the  global 
symbol  name  to  be  created  by  the  Ada  compiler.  This  name 
must  obey  the  naming  conventions  for  the  host  operating 
system's  object-module  format,  and  therefore  it  may  differ 
from  the  Internal  subprogram  or  object  name.  If  an  external 
name  Is  not  specified,  the  Internal  name  is  used  for  the 
symbol  name. 

a  Paramatar_Typea:  A  parenthesized,  comma-separated  list 
of  type  and/or  subtype  names  that  describes  the  param¬ 
eter-type  profile  of  an  exported  subprogram.  If  the  subpro¬ 
gram  has  no  parameters,  the  list  can  consist  of  the  single 
word  Null.  This  optional  argument  may  be  required  when 
the  Internal  argument  specifies  an  overloaded  subprogram. 
See  “Usage,’  below. 

■  The  result-type  profile  of  an  exported 
function.  This  optional  argument  may  be  required  when  the 
Internal  argument  specifies  an  overloaded  function.  See 
“Usage,"  below. 

■  Languaga:  The  name  of  the  language  in  which  the  calling 
code  Is  written.  The  only  language  name  currently 
supported  is  C;  always  use  this  value  when  exporting  to  C 
or  C++.  Other  language  names  are  ignored,  so  this 
argument  can  be  omitted  when  exporting  to  a  language 
other  than  C  or  C++. 

Usage 

Use  these  export  pragmas  to  create  globed  symbolic  names  for 
Ada  subprograms  that  will  be  called— or  Ada  objects  that  will  be 
referenced — from  non-Ada  code.  The  linker  will  use  these 
symbols  to  resolve  intermodule  references. 

If  the  internal  subprogram  name  is  overloaded,  you  must 
supply  enough  Information  for  the  compiler  to  determine 
unambiguously  which  subprogram  to  export.  Specify  the 
Parameter_Types  (and/or,  for  functions,  the  Result_Type)  so 
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Pragmas:  Pragmas  Export.Furrction,  Export_Ob]ect,  and  Export_Procedure 


that  the  compiler  can  construct  the  parameter-  and/or  result- 
type  profile  of  the  subprogram. 

Caution:  Exporting  a  subprogram  does  not  export  the  mecha¬ 
nism  used  by  the  compiler  to  perform  elaboration  checks.  A  call 
from  another  language  to  an  exported  subprogram  with  an 
unelaborated  body  may  produce  unpredictable  results  when  the 
subprogram  references  an  object  that  is  itself  unelaborated. 

A  Caution:  Accesses  to  Ada  objects  by  non-Ada  code  are  inher¬ 
ently  unsafe:  the  compiler  and  runtime  system  cannot  guarantee 
the  integrity  of  such  exported  objects.  It  is  the  developer's  respon¬ 
sibility  to  ensure  that  the  code  that  accesses  an  exported  object 
properly  interprets  and  maintains  the  underlying  structure  of  the 
object 

Notes 

■  An  export  The  pragma  can  appear  only  at  the  place  of  a 
declarative  Item  In  a  declarative  part  or  package  speclfica  - 
tion;  the  subprogram  or  object  to  which  It  applies  must 
have  been  declared  by  an  earlier  declarative  Item  of  the 
same  declarative  part  or  package  specification. 

■  An  exported  subprc^am  must: 

□  Not  be  a  generic 

□  Be  declared  in  a  static  scope;  that  Is,  it  must  not  be 
Inside  any  subprogram,  task,  generic  unit,  or  block 
statement 

■  An  exported  object  must: 

□  Not  be  In  a  generic  unit 
a  Be  a  variable 

□  Be  declared  in  a  static  scope;  that  is.  it  must  not  be 
Inside  any  subprt^ram,  task,  generic  unit,  or  block 
statement 

□  Have  a  static  size:  that  Is.  its  subtype  must  be  one  of; 

-  A  scalar  type  or  subtype 

-  An  array  subtype  with  static  index  constraints  whose 
component  size  Is  static 

-  An  undiscriminated  record  type  or  subtype 
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References  for  Subprograms 

■  elaboration  of  a  library  unit.  LRM  10.5 

■  order  of  elaboration.  LRM  3.9 

■  overloading.  LRM  8.3 

■  parameter  and  result  type  profile.  LRM  6.6 

■  ‘Calling  an  Ada  Subprogram  from  C”  on  page  8 

References  for  Objects 

m  limited  private  type.  LRM  7.4.4 

■  private  type.  LRM  7.4 

■  “Sharing  Global  Objects*  on  page  14 

Pragma  Generic_Policy 

Tells  the  compiler  how  to  generate  code  for  a  generic  package  or 

subprogram  and  its  Instantiations.  The  syntax  is: 

px«9iu  (aaDciacjE>oz.xcy 
([GEIlEmc_0K]:T»] 

[CODE  ->}  REPLxdiTBO  |  SHARED); 

Arguments 

■  Generlc_t7tilt:  The  simple  name  of  the  generic  package  or 
subprogram  to  which  the  pragma  applies. 

■  Coda:  A  keyword  that  specifies  whether  all  instantiations 
should  share  the  code  in  one  common  routine  (Shared),  or 
whether  each  instantiation  should  be  coded  separately 
(Replicated). 

Usage 

See  “Setting  Shared  or  Replicated  Generic  Policy"  on  page  22. 

Notes 

■  Use  pragma  lnstance_Pollcy  to  override  the  shared  Generic- 
_Pollcy  for  one  or  more  instantiations  of  a  generic  package 
or  subprogram.  See  “Pragma  Instance_Policy"  on  page  93. 

■  The  compiler  treats  all  generics  as  Replicated  unless  other¬ 
wise  specified  with  pragma  Generlc_Pollcy. 
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a  The  pragma  can  appear  only  at  the  place  of  a  declarative 
Item  in  a  declarative  part  or  package  specification;  the 
generic  to  which  tt.  applies  must  have  been  declared  by  an 
earlier  declarative  item  of  the  same  declarative  part  or 
package  specification. 

■  Any  generics  appearing  in  Apex  interface  views  must  be 
shared,  since  the  compiler  cannot  access  the  generic  body 
to  use  as  a  template  for  coding  replicated  instantiations. 

References 

■  generic  instantiation.  LRM  12.3 
a  generic  package.  LRM  12.1 

a  generic  subprogram.  LRM  12.1 
a  simple  name.  LRM  4. 1 

Pragmas  import_Function,  lmport_Ob]ect,  and  lmport_Procedure 

Associates  an  Ada  name  with  the  global  symbol  for  a  non-Ada 
subprogram  (function  or  procedure)  or  object  so  that  an  Ada 
subprogram  can  cal!  the  subprogram  or  reference  the  object. 
The  syntax  is: 


pragna 

ZMPCRT^rOHCTZOH 

->1 

intaznaI_naM 

([IHTKKHAIi 

[. 

[KXToana 

->1 

(aaRMBZEajmcs 

->1 

paraBeta^typa_Ii  •  t  ] 

[RISOLT_TZPB 

->1 

typm_Kmrk] 

[MEcmunsM 

->J 

amcbMni»m_li»t] ) ; 

pxagaw 

ZMPORT  OBJECT 

([ZHTBtHAL  ■>]  internal  nima 

[EXTXBBAL  aO-]  ”  ] ) ; 

pragma 

ZMPORT  PROCEDOSE 

([ZHTBOnL 

->1 

intaxnal_naae 

t. 

[EXTERSEL 

->1 

”axtaxnai_naae''  ] 

[. 

[PERAllETXRjrXPES 

->1 

pmrmmmtmr_typm_li»t] 

[MECHEBZail 

->1 

Mchanlei^Iiet] ) ; 

Arguments 

a  Zntarnal;  The  Ada  simple  name  of  the  non-Ada  subpro¬ 
gram  or  object  to  be  imported. 
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■  External;  An  optional  string  literal  that  specifies  the  global 
symbol  name  to  be  created  by  the  Ada  compiler.  Since  other 
languages  may  enforce  non-Ada-compatible  naming  con¬ 
ventions.  the  external  symbol  may  differ  from  the  internal 
subprogram  or  object  name.  If  an  external  name  is  not 
specified,  the  internal  name  is  used  for  the  symbol  name. 

m  Paraaiatar_Typas:  A  parenthesized,  comma-separated  list 
of  type  and/or  subtype  names  that  describes  the  param¬ 
eter-type  profile  of  an  imported  subprogram.  If  the  subpro¬ 
gram  has  no  parameters,  the  list  can  consist  of  the  single 
word  Null.  This  optional  argument  may  be  required  when 
the  Internal  argument  specifies  an  overloaded  subprogram. 
See  “Usage."  below. 

■  ReaultjType:  The  result-type  profile  of  an  imported 
function.  This  optional  argriment  may  be  required  when  the 
Internal  argument  specifies  an  overloaded  function.  See 
“Notes."  below. 

■  ttechanisa:  A  parenthesized,  comma-separated  list  of 
parameter-passing  mechanisms  for  the  parameters  passed 
by  a  subprogram.  If  the  imported  subprogram  has  parame¬ 
ters.  then  the  Mechanism  argument  is  required;  otherwise, 
do  not  Include  Mechanism.  There  must  be  a  one-to-one 
correspondence  between  the  passed  parameters  and  the 
mechanisms.  The  supported  mechanisms  are; 

□  valua;  The  corresponding  parameter  is  passed  by  value. 

Note:  When  interfacing  with  C  or  C++,  only  scalars  can  be 
passed  by  value:  Mechanism  must  always  be  Value  and 
the  corresponding  Ada  parameter  must  be  an  in  parameter 
for  scalars. 

□  Raferanca:  The  corresponding  parameter  is  passed  by 
reference;  that  is.  its  address  is  passed.  This  applies  to 
records  and  arrays  in  C  and  C++  and  to  C++  constant 
reference  parameters. 

If  all  of  the  Imported  subprogram’s  parameters  are  passed 
with  the  same  mechanism,  you  can  specify  a  single  occur¬ 
rence  of  the  mechanism  without  parentheses. 
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Usage 

Use  the  import  pragmas  to  supply  more  information  about  a 
non-Ada  subprogram  specified  with  pragma  Interface  or  a  non- 
Ada  object  to  be  referenced  by  Ada  code. 

E^rery  Imported  subprogram  must  be  described  both  by  pragma 
Interface  and  by  an  import  pragma,  in  that  order.  Pragma  Inter¬ 
face  is  ignored  if  there  is  no  corresponding  import  pragma,  or  if 
the  import  pragma  contains  errors. 

If  the  internal  Ada  subprogram  name  is  overloaded,  you  must 
supply  enough  Information  for  the  compiler  to  determine 
unambiguously  which  subprogram  is  being  imported.  Specify 
the  ParameterJIVpes  (and/or.  for  functions,  the  ResuIt_Type) 
so  that  the  compiler  can  construct  the  parameter-  and/or 
result-type  pro^e  of  the  subprogram. 

A  Caution:  Accesses  to  non- Ada  objects  from  Ada  code  are  inher¬ 
ently  unsafe:  the  compiler  and  runtime  system  cannot  guarantee 
the  integrtty  of  such  imported  objects.  It  is  the  developer's  re¬ 
sponsibility  to  ensure  that  the  code  that  accesses  an  imported  ob¬ 
ject  properly  Interprets  and  maintains  the  underlying  structure  of 
the  object 

Notes 

m  An  import  The  pragma  can  appear  only  at  the  place  of  a 
declarative  item  in  a  declarative  part  or  package  specifica¬ 
tion;  the  subprogram  or  object  to  which  it  applies  must 
have  been  declared  by  an  earlier  declarative  item  of  the 
ssune  declarative  part  or  package  specification. 

■  An  Import  pragma  must  not  refer  to  a  generic  subprogram. 

■  An  imported  object  must; 

□  Not  be  in  a  generic  unit 

□  Be  a  variable  declared  at  the  outermost  level  of  a  library- 
package  specification  or  body 

□  Have  a  static  size;  that  is.  lt«  subtype  must  be  one  of; 

-  A  scalar  type  or  subtype 

—  An  array  subtype  with  static  index  constraints  whose 
component  size  is  static 

-  An  undiscriminated  record  type  or  subtype 
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a  To  assign  an  imported  object  a  default  initial  value,  use 
pragma  Initialize.  See  ‘Pragma  Initialize”  on  page  92. 

References  for  Subprograms 

B  Interface  to  other  languages.  LRM  13.9 
a  pragma  Interface.  LRM  13.9 
a  scalar  types.  LRM  3.3 

a  ‘Calling  a  Non-Ada  Subprogram  from  Ada"  on  page  6 

References  for  Objects 

a  limited  private  type.  LRM  7.4.4 
a  private  type.  LRM  7.4 
a  ‘Sharing  Global  Objects"  on  page  14 

Pragma  Initialize 

Specifies  that  default  initialization  be  carried  out  for  an 
Imported  variable  or  a  variable  referenced  by  an  address  clause . 
The  syntax  is: 

pngma  XHXTXXLXZE 

Arguments 

a  aimpl«t_avae\  The  variable  to  which  default  initialization  is 
to  be  applied. 

Usage 

When  a  program  imports  a  variable  object  or  declares  a  variable 
with  an  address  clause,  the  compiler  assumes  that  this  variable 
previously  existed.  The  compiler  makes  no  attempt  to  assign  a 
default  (initial)  value  to  this  variable,  because  the  variable 
might  already  contain  a  valid  value  or  might  be  given  an  initial 
value  by  some  other  program.  By  default,  the  compiler  does  not 
perform  any  initialization  on; 

a  Variables  designated  by  address  clauses 

a  Imported  variable  objects:  see  ‘Pragmas  Import_Function. 
Import_Objcct.  and  Import.Procedure"  on  page  89 
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Pragma  Initialize  tells  the  compiler  to  assign  an  appropriate 
default  value  to  the  variable — ^for  example,  setting  pointers  and 
pointer  fields  to  null,  record  fields  to  the  Initial  values  present 
In  the  record  type  definition,  and  discriminants  to  their  proper 
values.  Hence,  the  variable  must  not  have  an  explicit  initial 
value. 

No  additional  storage  space  is  allocated  because  valid  variables 
already  exist. 

The  referenced  variable  must: 

a  Have  been  declared  earlier  In  the  same  declarative  part 
B  Be  an  array  or  record 

a  Have  an  associated  address  clause,  or  It  must  have  been 
imported  using  pragma  lmpoTt_ObJect  before  the  occur¬ 
rence  of  pragma  Initialize 
a  Not  have  an  explicit  Initial  value 

Example 

Pragma  Initialize  can  be  used  to  request  that  pointers  be  set  to 
Null  or  that  record  fields  be  given  some  starting  value. 

References 

a  address  clause.  LRM  13.5 
a  default  initialization.  LKM  3.2. 1 

Pragma  lnstance_Policy 

Specifies  how  to  generate  code  for  specific  instantiations  of  a 
generic.  The  syntax  Is: 

pxmgaw  ZH8TAaCS_P0LZCr 
([ZH8TAHTZAII0H  ->] 

[CODE  »]  UPLZCXTCO  |  SHARED)  ; 

Arguments 

a  Instantiation:  The  simple  name  of  the  specific  instantia¬ 
tion  to  which  the  pragma  applies, 
a  Coda:  A  keyword  whose  value  can  be  Replicated  or  Shared. 
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Usage 

Use  pragma  Instance.PoUcy  to  specify  whether  to  generate 
replicated  or  shared  code  for  specific  instantiations  of  generics. 

The  following  example  lllxistiates  the  use  of  the  pragma: 

—  SXCEMKaE_Z  and  KXCBURK_R  us*  thm  oesKm  sband 

—  oodn.  XXCSXMGKjB  UMs  Ita  own  ropliontnd  eodo. 

9on«xlo 

typo  aoMtypo  io  prlvoto; 
proooduzo  8wnp(X,  Y:  in  out  Soaotypo) ; 
pragma  Goaorlo_Polioy (Swap,  Sharod) ; 

pxoooduro  Bnohaago_R  i.a  now  Swap  (Somo typo  —>  Roal)  ; 
pxoooduxo  Sxohango_I  la  now  Swap (Somatypo  «>  Intogor) ; 
aubtypo  S  la  String (1 . . 100} ; 

proooduro  Kxohango_S  la  now  Swap (Soaotypo  *>  S) ; 
pragma  Znataaoo_Polloy(bohango_8,  Roplleatod) ; 

Notes 

B  The  pragma  is  ignored  if  the  Instantiation  refers  to  a  generic 
in  an  Apex  interface  view. 

■  The  pragma  and  the  named  Instantiation  must  occur  within 
the  same  declarative  part  or  package  specification. 

■  The  instantiation  must  occur  before  the  pragma. 

■  If  the  Instantiation  argument  refers  to  several  preceding 
overloaded  subprogram  Instantiations,  the  pragma  applies 
to  all  of  them. 

■  Only  one  pragma  Instance.PoUcy  can  be  appUed  to  each 
Instantiation. 

References 

e  ’Pragma  Generlc.PoUcy"  on  page  88 

■  “Setting  Shared  or  RepUcated  Generic  PoUcy"  on  page  22 

■  generic  Instantiation,  LRM  12.3 
B  generic  package.  LRM  12.1 

■  generic  subprogram.  LRM  12.1 

■  simple  name.  LRM  4. 1 
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Pragma  Main 

Designates  an  Ada  main  unit  and  determines  some  eispects  of 
its  runtime  behavior.  The  syntax  Is: 

pragaa  MSIH 

[  ( [DBtaCtJDBLDLOac  ■> 

[saas_sxzx  -> 

[SOKBLOCXIBOJEO  » 

[aC»XX_COMPLXMff  -> 

[SRKDIPTZVSjBCBSQULXBG  -> 

[8x<aDa._8ncxjBxzB  -> 

[szaacjixzs  » 

[TASX_PRXORXTX_ODAOLT  -> 

[TA8X_8TacX_8XZK_DZraULT 

■> 

[TXia_8LXCE  -> 

Arguments 

■  D«t«ct_psadlock:  Specifies  whether  the  Rational  Ada 
runtime  system  should  diagnose  deadlock  situations  In  the 
program.  If  True,  the  runtime  system  will  print  a  diagnosis 
of  what  Is  causing  the  tasks  to  block  when  deadlock  occurs. 
If  False,  the  program  simply  hangs.  The  default  is  False. 

a  H««p_six«:  A  nonnegative  static  integer  expression  that 
specifies  how  much  space  to  allocate  for  the  heap,  in  bytes, 
when  the  main  unit  begins  execution.  If  this  eirgument  Is 
specified,  no  additional  space  Is  allocated  to  the  heap  after 
Initialization:  requests  for  more  heap  space  raise  Storage- 
_EiTor. 

If  not  specified,  heap  space  Is  allocated  dynamically  as 
needed  until  space  is  exhausted  and  Storage_Error  is 
raised. 

■  Nonblocklng_Xo:  Specifies  whether  I/O  should  block  all 
tasks  in  the  pn^ram.  If  True,  only  the  task  performing  the 
I/O  blocks;  If  False,  the  entire  program  blocks.  For  a 
descTlpUon  of  limitations  and  operation,  see  “I/O  in  Tasking 
Programs”  on  page  34  and  “Using  Blocking  and 
Nonblocking  I/O"  on  page  58.  The  default  is  False. 


bool»»n_m3tprmmmion,  ] 
mt»t±e_iJitmgmr_mxprmmmion,  ] 
boelman_mxprm»mi.oa,  ] 
bool»mn_mxprmmB±on,  ] 
bodmBn_mxprm»mion,  ] 
»tBt±o_intmgmr_mxpT»mmion,  ] 
mtMtle_int»g»r_mxpTBmmj.on ,  1 
pr±ority_mxprBmmion, ] 

mtMtlo_intmgmr_mxprmMBion,  ] 
dbntioin_Mqpr«««i.on] )  ]  ; 
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■  PoaizjCo^llani::  Specifies  whether  certain  behavior 
described  by  the  IEEE  Portable  Operating  System  Interface 
(POSDQ  is  required.  If  True,  the  following  operational  char¬ 
acteristics  of  programs  compiled  and  linked  under  Rational 
Apex  are  affected: 

□  The  program  can  control  only  those  UNIX  signals  explic¬ 
itly  aUowed  by  POSIX.5  3.3.3. 1  (those  not  “reserved  for 
the  Ada  Implementation”). 

□  The  program  cannot  Install  an  interrupt-entiy  task  to 
handle  UNIX  signalo  that  the  runtime  system  uses,  nor 
can  It  Install  both  an  Interrupt-entiy  task  and  an  Ada 
procedural  signal  handler  for  the  same  signal  (POSIX.5 
3.3.2.1(963)). 

□  The  default  values  for  the  Form-parameter  fields  in  the 
Ada-predefined  I/O  packages  arc  the  POSrx.5  values 
rather  than  the  Apex  values,  as  described  In  “Field 
Defaults*  on  page  50. 

The  default  is  True. 

■  Pro«tinptivs_Seh«dulJ.ng;  Specifics  whether  preemptive 
(asynchronous)  task  scheduling  takes  place.  If  True,  all 
tasks  spawned  by  the  main  program  are  scheduled  preemp¬ 
tively.  The  default  is  False.  Task  scheduling  Is  described  in 
Chapter  5.  “Ada  Tasking  in  UNIX.” 

■  Slgnal_St«ck_Slx«:  An  Integer  expression  greater  than  or 
equal  to  2,048  (2  Kb)  that  specifies  the  size  of  the  signal 
stack,  in  bytes.  The  Rational  Ada  runtime  system  uses  this 
stack  for  handling  runtime  signals,  and  the  debugger  uses 
this  stack  for  special  type  display.  If  not  specified,  the 
default  signal  stack  size  is  64  Kb.  When  the  program  is  run 
under  the  debugger,  the  default  stack  size  is  increased  to 

2  Mb. 

■  StackjSlza:  A  static  Integer  expression  greater  than  or 
equal  to  2.048  (2  Kb)  that  specifies  the  size  of  the  main  task 
stack,  in  bytes.  If  not  specified,  the  default  stack  size  is 

2  Mb. 

■  T«8k_PriorltyJD«f*ult:  An  expression  of  type  System- 
.Prlority  that  specifies  the  priority  for  ai^  task  without  a 
pragma  Priority.  The  default  Is  the  same  as  the  main  task's 
priority:  if  the  main  task  is  not  given  a  priority,  the  default 
is  127. 
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■  '•'aaV_«t«ck_fli**_Pa«ault:  A  static  Integer  expression 
greater  than  or  equal  to  2.048  (2  Kb)  that  specifies  the  size, 
in  bytes,  of  the  stack  for  ai^  task  without  a  'Storage.Size 
representation  clause.  The  default  is  64  Kb. 

a  TlBMt_siic«:  A  nonnegative  expression  of  type  Standard- 
.Duratlon  that  determines  the  quantity  of  time  to  allocate  to 
an  executing  task.  By  default,  or  If  the  value  is  zero,  no  time 
slicing  Is  used.  This  has  an  effect  only  in  conjunction  with 
preemptive  scheduling;  otherwise,  it  is  ignored. 

Usage 

Use  pragma  Main  after  the  end  of  the  unit  body  of  any  pa¬ 
rameterless  library-unit  procedure  to  designate  It  as  a  main 
program. 

Pragma  Main  can  have  two  effects.  It: 

■  Causes  the  unit  to  be  linked  automatically  If  it  is  In  the 
directory  or  view  for  which  you  have  requested  Unking; 
main  units  without  pragma  Main  are  not  linked  unless 
expUcltly  requested. 

■  Permanently  specifies  the  size  of  various  code  sections  and 
the  mode  of  operation  for  the  executable  program  resulting 
from  a  link 

Example 

Use  pragma  Main  as  shown: 

proo«dur«  Shoir_lUiji  is 
b«9la 

Do_8oMtMxig; 

•nd  Shoir_llsin; 

prsgas  Mala  (StaokjSis*  >>  10*1024);  --Chang*  to  10  Kb 

Notes 

■  AU  arguments  can  be  specified  using  Apex  session  switches 
to  change  the  options  dynamically  at  runtime.  The  switches 
have  the  same  names  as  the  arguments,  in  all  uppercase, 
with  the  prefix  AFEX_.  ElxpUclt  use  of  an  argument  on 
pragma  Main  overrides  the  switch  vedues. 


7x9"  Printed  Template,  rev.  1 .9 


97 


Chapter  10  LRM  Appendix  F:  lmplenfientation*[)ependent  Characteristics 


References 

m  library  unit.  LRM  10.1 

■  main  program.  LRM  10.1 

a  heap  and  stack  allocation,  ‘Miscellaneous  Memory  Manage¬ 
ment”  on  page  64 

Pragma  Must_Be_Constrained 

Indicates  whether  formal  private  and  Umlted  private  types 
within  a  generic  formal  part  must  be  constrained  or  have 
default  values.  The  syntax  is: 

pngma  1I08T_BS_OOHSTIUIZKKD 
iooadltlon_llat) ; 

Arguments 

■  concU.tion_list:  A  comma-separated  list  of  conditions 
that  spedfles  a  set  of  types  and  whether  each  set  must  be 
constrained  or  have  dtfault  values.  Each  element  of  the 
condition  list  has  the  format: 

[oondieion  ■>] 
where; 

□  coaditioa:  Can  be  either  YES  or  NO.  If  omlt^“d.  the 
default  is  YES.  Determines  the  setting  for  eiU  t>  pes  in  the 
following  type  ID  list. 

□  typ»_id_list:  A  comma-separated  list  of  formal  private 
or  limited  private  tsrpes.  These  types  must  be  defined  in 
the  same  formal  part  as  the  pragma. 

Usage 

Use  pragma  Must_Be_Constralned  to  specify  how  you  intend  to 
use  the  formal  parameters  in  a  generic  specification. 

Each  condition  controls  the  types  in  the  following  type  ID  list, 
until  the  next  occurrence  of  a  condition.  Consider  this  example: 

pngna  lla«t_B«_Con«txalz>«d 

>t^>Typ«_2,  Typ«_3,  YXS->Typ«_4,  Typ«_5)  ; 

At  the  beginning  of  the  list,  a  condition  is  not  specified,  so  yes 
is  assumed;  hence.  Type_l  is  constrained,  no  controls  the 
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following  type  ID  list,  which  Includes  Typc_2  and  TVpe.S; 
hence,  they  are  unconstrained,  ws  controls  the  remaining  type 
ID  list,  so  Typc_4  and  Type_5  are  constrained. 

Notes 

If  the  condition  NO  is  specified,  any  use  in  the  body  that 
requires  a  constrained  t5T>e  will  generate  a  semantic  error.  If 
YES  Is  specified,  any  Instantiations  that  contain  actual  param¬ 
eters  that  require  constrained  types  will  generate  semantic 
errors  If  the  actual  parameters  are  not  constrained  and  have  no 
default  values. 

References 

■  constrained  private  type.  LRM  7.4.2 

■  generic  formal  type.  LRM  12 

■  matching  rules  for  formal  private  types.  LRM  12.3.2 

■  limited  private  type.  LRM  7.4.4 

■  private  type  as  generic  formal  t)T)e.  LRM  12.1.2 

Pragma  Signal_Handler 

Installs  an  Ada  procedure  as  a  UNIX  signal  handler.  The  syntax 
is: 

pragM  8XGKXL_HaBDLXR 

(HMIC  timplmjnsam, 

8ZGKAL  >>  ±atmgmr_mxprm»»ioii) ; 

Arguments 

■  nssm:  The  simple  Ada  name  of  the  signal-handling 
procedure. 

■  Signal:  A  nonstatic  Integer  expression  specifying  the  UNIX 
signal  number  to  be  handled  by  the  specified  procedure. 

Usage 

Elaboration  of  the  pragma  has  the  effect  of  Installing  the  spec¬ 
ified  procedure  as  a  signal  handler  for  the  given  signal;  subse¬ 
quent  occurrences  of  the  specified  signal  will  cause  the 
specified  procedure  to  be  Invoked. 
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The  pragma  and  the  procedure  body  must  occrir  in  the  same 
declarative  part,  with  the  pragma  following  the  procedure  body. 
This  prevents  the  Installation  of  a  procedure  whose  body  has 
not  yet  been  elaborated. 

See  “Ada  Procedural  Signal  Handlers’  on  page  43  for  details  on 
the  construction  of  the  procedure. 

References 

■  simple  name.  LRM  4. 1 

■  declarative  part,  LRM  3.9 

Pragma  Suppress_AII 

Suppresses  all  permitted  runtime  checks.  The  syntax  is: 

pragma  S0PPiaE8S_AlX; 

Arguments 

None. 


Usage 


Use  pragma  Suppress_AD  to  create  the  same  effect  as  all  of  the 
following: 


pragma  Supprmsa 
pragma  Supprasa 
pragma  Supprasa 
pragma  Supprasa 
pragam  Supprasa 
pragma  Supprasa 
pragma  Supprasa 
pragma  Supprasa 
pragma  Supprasa 


(Aoeaaa__Chaek) ; 
(Dlsorimlnant_Cbaok) ; 
(DivisiQn_Chaok) ; 
(Klaboraeion_Chaek) ; 
(Zadaz_Cbaok) ; 
(I<angth._Chaok) ; 
(Ovar£loM'_Cbaok) ; 
(Storaga_Chaok) ; 
(Ranga_Chaok) ; 


Notes 

m  Pragma  Suppress _A11  has  no  eflect  In  a  package 
speclflcaUon. 

■  The  pragma  must  appear  Immediately  within  a  declarative 
part. 
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References 

a  suppressing  checks.  LRM  11. 

Pragma  Suppress_Elaboration_Checks 

Suppresses  all  elaboration  checks  In  a  given  compilation  unit. 
The  syntax  Is; 

pragna  8\xppr«a«_Elabora^lon_C3i*elcs; 

Arguments 

None. 

Usage 

Use  pragma  Suppress_Elaboratlon_Checks  after  the  end  of  the 
unit  body  of  any  compilation  unit  to  suppress  elaboration 
checks  for  all  subprograms  In  that  unit.  This  Is  equivalent  to 
placing  a  named  pragma  Suppress  (Elaboratlon_ChecW  on 
each  subprogram  In  the  unit. 

References 

■  suppressing  checks.  LRM  1 1.7 


Attributes 


Table  10-3  summarizes  all  Implementation-defined  attributes 
In  Rational  Ada.  E^ch  attribute  is  described  In  more  detail  in 
the  following  subsections. 


Table  JO-3  Implementation-Deflnad  Attributes 


Attribute 

Meaning 

■CompUer_Key 

Identifies  the  compiler  used  to  generate  code 
for  the  specified  object 

’Compller_Verslon 

Yields  the  version  of  the  compiler  used  to  gen¬ 
erate  code  for  the  specified  object 

'Dope_Address 

Yields  the  address  of  the  dope  vector  for  an 
array  object 
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Table  1(^3  Impiementation-D^iftned  Attributes  (Continued) 


Attxlbate 

Ifeaiilsg 

■E>ope_Slze 

Yields  the  size  of  the  dope  vector  for  an  array 
object 

'Entry_Nuinber 

Unlquefy  Identifies  an  entry  or  generic 

'Homogeneous 

Specifies  vdiether  objects  in  a  collection  are  of 
uniform  size 

Type.Key 

Uniquely  identifies  a  type 

’Compller_Key 

For  a  prefix  N  that  denotes  the  name  of  an  entity,  n  ’  Conpiler- 
_K«y  yields  the  full  pathname  of  the  compiler  key,  which  indi¬ 
cates  the  compiler  that  was  used  to  generate  code  for  the  unit 
containing  the  definition  of  N. 

The  entity  named  by  N  can  be  a  program  unit  (package,  subpro¬ 
gram.  task,  or  generic),  an  object  (variable,  constant,  named 
number,  or  parameter),  a  type  or  subtype  (but  not  an  Incom¬ 
plete  type),  or  an  exception. 

The  value  returned  by  this  attribute  Is  of  type  String;  for 
example.  " /rnv_hoo»»/k«y8/ada_r«tional_rs6k_aix" . 

This  attribute  can  be  used  for  runtime  detection  of  incompati¬ 
bilities  In  data  representation.  It  typically  Is  used  when  passing 
messages  over  a  network  to  ensure  that  the  reader  and  writer 
agree  on  how  to  interpret  the  message.  See  also  ’Compiler - 
_Version. 

’Compller_Verslon 

For  a  prefix  N  that  denotes  the  name  of  an  entity.  N '  Coii?>iler- 
_Ver8ion  yields  the  version  of  the  compiler  that  was  used  to 
generate  code  for  the  unit  containing  the  definition  of  N. 

The  entity  named  by  N  can  be  a  program  unit  (package,  subpro¬ 
gram.  ta^,  or  generic),  an  object  (variable,  constant,  named 
number,  or  parameter),  a  type  or  subtype  (bui  not  an  incom¬ 
plete  type),  or  an  exception. 


102 


7x9"  Printed  Template,  rev.  1 .9 


Attributes:  ’Dope_Address 


The  value  returned  by  this  attribute  Is  of  type  string;  for 
example.  "11.4.0". 

This  attribute  can  be  used  for  runtime  detection  of  incompati¬ 
bilities  in  data  representation.  It  typically  is  used  when  passing 
messages  over  a  network  to  ensure  that  the  reader  and  writer 
agree  on  how  to  interpret  the  message.  See  also  ■Compller_Key. 

’Dope_Address 

For  an  array  object  A,  A'Dope_Address  yields  the  address  of 
the  dope  vector  that  describes  A.  The  value  is  of  type  System- 
Address.  If  the  object  denoted  by  A  has  no  dope  vector,  this 
value  Is  0. 

This  attribute  can  be  used  in  conjimctlon  with  ’Dope_Size  for 
retrieving  information  about  the  object,  as  when  reconstructing 
the  array  when  passlrig  messages  over  a  network.  See  “Dope 
Vectors”  on  page  76  for  additional  information. 

’Dope_Slze 

For  an  array  object  A.  A'Dopa_Six*  yields  the  size  in  bits  of  the 
dope  vector.  The  value  is  of  type  Unlvcrsaljnteger. 

A  positive  value  is  always  returned,  whether  or  not  the  object 
denoted  by  A  has  a  dope  vector.  Use  T)ope_Address  to  deter¬ 
mine  whether  the  dope  vector  actually  exists. 

This  attribute  can  be  used  for  retrieving  information  about  the 
object,  as  when  reconstructing  the  array  when  passing 
messages  over  a  network.  Sec  "Dope  Vectors*  on  page  76  for 
additional  Information. 

’Entry_N  umber 

For  a  prefix  E  that  denotes  a  task  entry  or  generic  formal 
subprogram.  B '  Bntxy_Nunib*r  yields  a  Unlversal_Integer  value 
that  uniquely  identifies  the  entity  denoted  by  E. 

’Homogeneous 

For  a  prefix  T  that  denotes  an  access  type,  t  '  Homogeneous 
yields  a  Boolean  value.  The  value  returned  is  True  if  all  objects 
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in  the  coUectlon  will  always  have  the  same  constraints.  The 
converse,  however,  is  not  true. 

Applying  this  attribute  to  a  type  that  is  not  an  access  value  is  a 
semantic  error. 

Note  that  the  attribute  is  a  property  of  the  type,  not  of  the 
subtype.  Thus,  for  any  access  t^e  T.  T  •  Homogeneous  yields  the 
same  value  as  T '  Base '  Homogeneous. 

For  example: 

type  T1  is  sooeas  Spring  (1..10); —  T1 'BoaoganaousBTrua 

type  T2  1«  aaoaa*  Spring;  —  T2 'Boaogenaoua=rals« 

typ*  T3  la  new  T2  (1  ..  10);  —  T3’Hon»geneouavralaa 

type  T4  la  new  T1 ;  —  T4 ' BonogeneouasTrue 

At  the  implementation  level,  the  attribute  indicates  whether 
constraint  information  is  stored  with  allocated  objects. 


’Type_Key 

For  a  prefix  T  denoting  a  type  name.  T '  TypejKey  yields  a  string 
that  uniquely  identifies  type  T.  This  attribute  typically  is  used 
when  passing  messages  a  given  type  over  a  network  to  ensure 
that  the  reader  and  writer  agree  on  the  type  to  use  when  inter¬ 
preting  the  message. 

Attributes  of  Numeric  Types 

This  section  lists  the  values  returned  by  attributes  that  apply 
to  Integer  types. 

Integer  Types 

The  attributes  that  apply  to  integer  types — namely,  ’First.  'Last, 
and  'Size — ^yleld  the  values  shown  below  for  the  predefined  base 
type: 


Table  10-4 

Attribute  Valueefor  Integer  Types 

Attribute 

Value 

•Hrst 

_231 

Tast 

23>-1 

Size 

32 
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Packages  Standard  and  System 


This  section  contains  the  specifications  for  packages  Standard 
and  System. 

Package  System  (LRM  13.7) 

Paekag*  SyatM  ia 

typa  Addsass  ia  privata; 

typa  SaaM  ia  (Spaxo_Solaria) ; 

Syataak_Naaa  :  ooaatant  Haaa  Sparo_Sunos; 
8tora9a_0ni't  :  eoaateaat  8; 

MamDzy_8ixa  :  eoaatant  :>  +(2  **  31)  -  1; 

llin_Xnt  :  oona^aat  -(2  **  31); 
ltox_Xnt  :  eoaatant  :•  +(2  **  31)  -  1; 

ltoz_01gita  :  eoaatant  :>  15; 
llaz_lfaatiaaa  :  oeoataat  :■  31; 
rinaJDalta  :  eoaatant  :■  1.0  /  (2.0  **  31); 

Tiok  :  oonataat  :«  1.0  /  60.0; 

aobtyp*  Priority  ia  Intogar  range  0  . .  255; 

Aaaartion_Error  :  axooption; 

function  To_Addraaa  (Value  :  Integer)  return  Address; 
function  To_lateger  (Value  :  Address)  return  Integer; 

function  ”•¥"  (Left  :  Address;  Rigbt  :  Integer) 
return  Address; 

function  "-t-"  (Left  :  Integer;  Riglit  :  Address) 
return  Address ; 

function  (Left  :  Address;  RigAit  :  Address) 

return  Integer; 

function  (Left  :  Address;  Right  ;  Integer) 

return  Address; 

funotion  "<**  (Left,  Right  :  Address)  return  Boolean; 
function  "Km"  (Left,  Right  :  Address)  return  Boolean; 
function  (Left,  Right  :  Address)  return  Boolean ; 
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fanetloa  (L*£t,  Right  :  Addx«««)  return  Booi«*n; 

—  Tha  foaotiOM  abowm  an  unslgnad  in  natun.  Nalthar 

—  HmarloJBrxor  nor  Conatnint_Bxror  will  avar  ba 

—  pxopagatad  by  ttaaaa  funetlona. 

—  Conaaquaatly, 

—  To_Aiddnas  (Zatagax* first)  > 

—  To_Jkddnas  (Xntagar'lAst) ; 


—  To_Addnss  (0)  <  To_Jlddrass  (-1) ; 

— —  Tba  unslgnad  ranga  o£  Xddxass  Inoludas  valuas  that 

—  an  largar  than  thosa  Isipliad  fay  Maaoxy_SiKa. 

Jlddrass__Zan  :  constant  JLddrass; 

I)ull_Addnss  :  constant  hddnss; 

Ko  Addr  :  constant  Addnss; 


private 


typa  Addnss  is  naw  Xntagar; 


Addrass__Zaro  :  constant  Addnss  0; 

Roll_Addnss  :  constant  Addrass  0; 

No  Addr  ‘  constant  Addnss  :>  0; 


pragaa  duppnss  (Klafaoration_CSiaek, 
pragma  Suppnss  (Klaboration_Cbaok, 
pragma  Suppress (Elafaoratlon_Chaofc, 
pragsm  Suppnss  (Rlaboratlon_Q>aclf , 
pragma  Suppnss  (Klaboratlon_Cbaok, 
pragma  Suppnss  (Klafaontion_Qiaok, 
pragma  Suppnss  (Xlafaoration_aMok, 
On  ^  System.  To_Addnss ) ; 
pragaa  Suppnss  (Klaboratlon_Chack, 
On  a>  System.  To^Zntagar)  ; 


On  ■«>  System. 

On  »>  System."-"); 
On  ■>  System. ; 
On  ■>  System. ">»")  ; 
On  ->  System. ; 
On  ■>  System.  "<=" ) ; 


pragaa  Inline  (System,  "■f” ) ; 
pragma  Inline (System. ; 
pragma  Inline  (System.  ">" ) ; 
pragma  Inline  (System.  ">«")  ; 
pragaa  Inline  (System.  "<'* ) ; 
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pxagaa  Xnlia*  (SjratMi.  ; 
prsQM  ZnllA*(fly«tMi.To_SddMas)  ; 
pxagiM  Xnlln«(8y«t«M.To_Znt«9*r)  ; 

•ad  Syatwi; 

Package  Standard  (LRM  Annex  C) 

paoJcmg*  Standard  la 

typ«  *anlTaraal_Xnt*g*r*  la  _ 

typ*  *QalTaraal_l(aal*  la  ... 
typ«  *ailT*raaljrix*d*  la  . . . 
typ*  Boolaan  la  (Talaa,  Txua) ; 

typa  Xntagar  la  raaga  -2X47483648  ..  2147483647; 
typ«  rioat  la  dlglta  6 

rang*  -((2.0  **  128)  -  (2.0  **  104))  .. 

((2.0  **  128)  -  (2.0  **  104));—  about  3.4Z+38 
typ*  Lang_rioat  la  dlglta  15 

rang*  -((2.0  1024)  -  (2.0  **  971))  ., 

((2.0  **  1024)  -  (2.0  **  971));  —  about  1.8S+308 

aubtyp*  Batumi  la  Xatagor  rang*  0  . .  2147483647; 
aubtyp*  Poaltlv*  la  Xat*g*r  rang*  1  ..  2147483647; 
typ*  Duration  la  dalta  0.000061035156 
rang*  -131072.00000000  .. 

0131071 . 9999389648437500000000 ; 
typ*  Cbamot*r  la  . . . 

paoJcag*  Aaoll  la . . . 

typ*  String  la  army  (Poaltlv*  rang*  <>)  of  Cbaxactar; 
Conatraint_Crror  :  *zc*ptlon; 

RUB*rlo_Krror  :  *xo*ptlon; 

Storag*_Krror  :  *ra*ptlon; 

Taaklng_Krror  :  *zo*ptlon; 

Progmai_Krror  :  *xe*ptlan; 
typ*  *Anytyp**  la 
raoord 
null; 

*nd  raoord; 
and  Standard; 

The  following  table  shows  the  sizes  of  predefined  Integer  and 
floating-point  types; 
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Table  iOnS  Slaceqf  Predefined  Numeric  Types 


Ada  Type  Name 

8Iae 

Integer 

32  bits 

Float 

32  bits 

Long_F1oat 

64  bits 

Ptxed-polnt  types  are  implemented  using  32  bits. 

Floating-point  types  are  implemented  according  to  the  IEEE 
Standard  for  Binary  Floating-Point  Arithmetic  lANSI/IEEE  Std. 
754-1985). 

Standard-Duration  is  a  32-blt  fixed-point  ts^ie  with  a  delta  of 

2-14. 

Representation  Clauses  _ 


This  section  discusses  limitations  on  representation  clauses  in 
the  following  categories: 

m  ‘Representation-Clause  Error  Handling’  on  page  108 

■  ‘Length  Clauses*  on  page  109 

a  ‘Record  Representation  Clauses  (LRM  13.4)"  on  page  1 10 
m  ‘Enumeration  Representation  Clauses  (U^  13.3)’  on 
page  110 

■  ‘Change  of  Representation  (LRM  13.6)’  on  page  1 10 
For  related  information,  see  Chapter  9.  ’Sizes  of  Objects.’ 

Representation-Clause  Error  Handling 

Normally,  an  invalid  representation  clause  causes  an  error  at 
compile  time  and  prevents  successful  compilation. 

Several  Apex  context  switches,  howewr,  aUow  you  to  specify 
whether  to  treat  certain  classes  of  invalid  representation 
clauses  as  nonfatal  errors  that  allow  succeskul  compilation 
rather  than  as  errors.  Sec  Appendix  A,  ‘Switches.’  and  Using 
Rational  Apex  for  details  on  the  foUowing  switches: 
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B  Ignore_Iiivalid_Rep_Specs:  Affects  the  handling  of  both 
Invalid  and  unsupported  representation  specifications, 
a  Ignore_UnsuppoTted_Rep_Specs:  Affects  the  handling  of 
unsupported  representation  specifications  only. 

Length  Clauses 

Length  clauses  are  never  allowed  on  derived  record  types; 
otherwise,  length  clauses  are  supported  by  Rational  Ada  as 
follows: 

a  The  value  of  a  ’Size  attribute  must  be  a  positive  static 
Integer  expression.  It  must  be  greater  than  or  equal  to  the 
minimum  size  mcessary  to  store  the  largest  possible  value 
of  the  type.  ‘Size  attributes  are  supported  for  all  scedar  and 
composite  types  with  the  following  restrictions: 


Table  10-6  'Sixe  Attribute  Restrictlona 


Type* 

Legal  Attribute  Values 

Access  and  task 

32 

Composite 

Must  not  imply  compression  of  composite 
components;  such  compression  must  have 
been  explicitly  requested  using  a  length  clause 
or  pragma  Pack  on  the  component  type 

Discrete 

Less  than  or  equal  to  32 

Fixed-point 

Less  than  or  equal  to  32 

Floating-point 

Can  specify  onfy  the  size  the  type  would  have 
if  there  were  no  clause;  therefore,  the  only 
legal  values  are  32  and  64 

a  'Storage.Size  attributes  are  supported  for  access  and  task 
types.  The  value  given  by  a  ‘Storage.Slze  attribute  can  be 
any  Integer  expression,  and  It  Is  not  required  to  be  static, 
a  ‘Small  attributes  are  supported  for  fixed-point  types.  The 
value  given  by  a  'Small  attribute  must  be  a  positive  static 
real  number  that  cannot  be  greater  than  the  delta  of  the 
base  type.  It  need  not  be  a  power  of  2. 
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Enumsration  Representation  Clauses  (LRM  13.3) 

Enumeration  representation  clauses  are  supported  with  the 
following  restriction; 

a  The  allowable  values  for  an  enumeration  clause  range  from 
IntegerTlrst  to  IntegerTast. 

Record  Representation  Clauses  (LRM  13.4) 

Both  full  and  partial  representation  clauses  are  supported  for 
both  discriminated  and  undiscriminated  records.  Record 
component  clauses  are  not  allowed  on; 

a  Array  or  record  fields  whose  constraint  involves  a  discrimi¬ 
nant  of  the  enclosing  record 
■  Array  or  record  fields  whose  constraint  Is  not  static 

The  static  simple  expression  in  the  alignment  clause  part  of  a 
record  representation  clause — see  the  Ada  LRM  13.4  (4) — must 
be  a  power  of  2  with  the  following  limits: 

1  <■  •e«tia_siJBpl«_«acpx«««ion  <•*  16 

The  size  specified  for  a  discrete  field  in  a  component  clause 
must  not  exceed  32  bits. 

Change  of  Representation  (LRM  13.6) 

Change  of  representation  is  supported  wherever  It  is  implied  by 
support  for  representation  specifications.  In  particular,  type 
conversions  between  array  t^es  may  cause  packing  or 
unpacking  to  occur,  conversions  between  related  enumeration 
types  with  different  representations  may  result  In  table-lookup 
operations. 

Implementation-Generated  Names  _ 


The  Ada  LRM  allows  for  the  generation  of  names  denoting 
Implementation-dependent  components  in  records.  No  such 
names  are  visible  to  the  user  for  Rational  Ada. 
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Address  Clauses  (LRM  13.5} 


Address  clauses  cannot  be  applied  to  task  types.  No  other 
restrictions  are  placed  on  address  clauses. 

An  address  clause  can  be  attached  to  a  task  entry  only  when 
the  task  entry  Is  used  for  signal  (Interrupt)  catching:  however, 
in  this  case,  the  task  entry  must  be  available  at  the  time  of  the 
signal.  See  the  discussion  of  pragma  Slgnal.Handler  on 
page  9S  and  "Interrupt-Entry  Tasks"  on  page  40  for  additional 
information. 

Values  of  address  clauses  are  not  checked  for  validity.  No  check 
is  made  to  determine  whether  an  address  clause  causes  the 
overlay  of  objects  or  of  program  units. 

Unchecked  Programming 


Unchecked  Storage  Deallocation  (LRM  13.10.1) 

Unchecked  storage  deallocation  Is  Implemented  by  the  Ada 
LRM-deflned  generic  fimctlon  Unchecked_Deallocation.  This 
procedure  can  be  instantiated  with  an  object  type  and  its 
access  type,  resulting  in  a  procedure  that  deallocates  the 
object’s  storage.  Objects  of  any  type  can  be  deallocated. 

The  storage  reserved  for  the  entire  collection  associated  with  an 
access  type  Is  reclaimed  when  the  program  exits  the  scope  in 
which  the  access  type  is  declared.  Placing  an  access-type  decla¬ 
ration  within  a  bl(^  can  be  a  useful  implementation  strategy 
when  conservation  of  memory  is  necessary  within  a  collection. 
Space  on  the  free  list  is  coalesced  when  objects  are  deallocated. 

Erroneous  use  of  dangling  references  may  be  detected  in 
certain  cases.  When  detected,  the  Storage_Error  exception  is 
raised.  Deallocation  of  objects  that  were  not  created  through 
allocation  (that  is.  through  Unchecked_Converslon)  may  also 
be  detected  in  certain  cases,  also  raising  Storage.Error. 

Unchecked  Type  Conversion  (LRM  13.10.2) 

Unchecked  type  conversion  is  implemented  by  the  generic 
function  Unchecked.Converslon  defined  by  the  Ada  LRM.  This 
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function  can  be  instantiated  with  source  and  target  types, 
resulting  In  a  function  that  converts  source  data  values  into 
target  data  values. 

Unchecked  type  conversion  moves  storage  units  from  the 
source  object  to  the  target  object  sequentially,  starting  with  the 
lowest  address.  Transfer  continues  vmtll  the  source  object  is 
exhausted  or  the  target  object  runs  out  of  space.  If  the  target  is 
larger  than  the  source,  the  remaining  bits  are  undefined. 
Depending  on  the  target-computer  architect,  the  result  of 
conversions  may  be  right-  or  left-justified. 

Restrictions  on  Unchecked  Type  Conversion 

The  following  restrictions  apply  to  imchecked  type  conversion; 

■  The  target  type  of  an  tmchecked  type  conversion  cannot  be 
an  imconstralned  array  t3T)e  or  an  unconstrained  discrimi¬ 
nated  type  without  default  discriminants. 

■  Internal  consistency  among  components  of  the  target  type 
is  not  guaranteed.  Discriminant  components  may  contain 
Illegal  values  or  be  inconsistent  with  the  use  of  those 
discriminants  elsewhere  In  the  type  representation. 

Input/Output  Packages 


The  Ada  language  defines  specifications  for  four  I/O  packages; 
Sequentlaljo.  Dlrectjo.  Low_Level_Io.  and  Textjo.  The 
following  subsections  explain  the  implementation-dependent 
characteristics  of  those  four  packages  provided  with  Rational 
Ada. 

SequentiaIJo  (LRM  14.2.2  and  14.2.3) 

For  the  Read  procedure  of  Sequentlal_Io.  the  Data_Error  excep¬ 
tion  Is  raised  only  when  the  size  of  the  data  read  from  the  file  is 
greater  than  the  size  of  the  out  parameter  Item. 

POSIX  Compliance 

The  Form  parameter  on  subprograms  In  SequentiaIJo  is 
compliant  with  the  POSIX.5  standard  to  the  extent  described  in 
Chapter  7,  ‘Files  and  I/O." 
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DIrectJo  (LRM  14.2.4) 

Package  Directjo  may  not  be  Instantiated  with  any  type  that  is 
either  an  unconstrained  array  type  or  a  dlscrtmlnated  record 
type  without  default  discriminants.  A  semantic  error  is  reported 
when  an  attempt  Is  made  to  Install  any  unit  that  contains  an 
Instantiation  In  which  the  actual  type  is  such  a  forbidden  type. 

For  the  Read  procedure  of  Directjo,  no  check  Is  performed  to 
ensure  that  the  data  read  from  the  file  can  be  interpreted  as  a 
value  of  the  ElementJType. 

Specification  of  Package  Directjo  (LRM  14.2.5) 

The  declaration  of  the  type  Count  In  package  Dlrect_Io  is: 

typ*  Count  la  now  Intogor  rang*  0  ..  Intogor'Laat  / 

El  niont_Typo ' Six*; 

where  ElementJType  is  the  generic  formal  type  parameter. 

POSiX  Compiiance 

The  Form  parameter  on  subprograms  In  Directjo  is  compliant 
with  the  POSIX.5  standard  to  the  extent  described  in  Chapter 
7.  -FUes  and  I/O." 

Low_LeveiJo  (LRM  14.6) 

Package  Low_LevelJo  Is  not  provided  with  Rational  Ada. 

Text  Jo  (LRM  14.3) 

The  Text  Jo  default  Input  and  output  files  are  associated 
with  the  UNIX  standard  Input  and  standard  output  paths, 
respectively. 

Specification  of  Package  Text  Jo  (LRM  14.3.10) 

The  declaration  of  the  type  Count  In  Text  Jo  Is: 

typ*  Count  1«  n*w  lnt*g*x  r*ng*  0  ..  1_000_000_000; 

The  declaration  of  the  subtype  Field  In  Text  Jo  Is: 

•ubtyp*  Fl*ld  1*  Znt*g*x  rang*  0  ..  Znt*g*x'Ii*st; 
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File-Management  Operations 

The  operations  of  Get  and  Put  are  as  described  in  the  Ada  LRM. 

Data  written  using  Put  and  Put_Llne  is  not  Interpreted  In  any 
fashion.  Data  written  using  Put_Llne  Is  followed  by  the  line 
terminator  Ascll.Lf. 

Data  read  using  Get  and  Get_Llne  Is  not  Interpreted  except  that 
the  line  terminator.  AsdLli,  and  the  page  terminator.  AscU.Ff, 
are  removed  from  the  Input  stream. 

POSIX  Compliance 

The  Form  parameter  on  subprograms  In  Textjo  Is  compliant 
with  the  POCDLo  :>.andard  to  the  extent  described  in  Chapter 
7.  “Files  and  I/O." 

Other  Implementation-Dependent  Features 

Machine  Code  (LRM  13.8) 

Machine-code  Insertlotvs  are  not  supported  at  this  time. 
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